An Instruction-Set Architecture (referred to herein as an "architecture") is the definition of the logical view of a computer as seen by an Assembly Language programmer. It includes a description of the logical storage that can be operated on by an assembly-language program (i.e., the visible memory hierarchy, the addressing structure, I/O devices, and the explicit and implicit registers within the processor). It includes a list of all instructions that can be executed by the assembly-language program (e.g., LOAD, ADD, BRANCH, etc.) with the precise format of each instruction, and a complete description of what the result of executing the instruction will be under all possible circumstances. Finally, it includes a complete description of what can possibly be observed by other processors that are examining the contents of shared storage as a program executes on the processor.
Two processors are said to have the same architecture if the description of their operations given at the level described in the preceding paragraph are the same. A more rigorous statement is as follows: two machines, A and B, have the same architecture if there is no program that can produce an output when run on processor A that could not possibly be an output when run on processor B.
What an architecture specifically does NOT include is a description of the actual hardware in the machine. That is, the architecture does not say how many arithmetic logic units are in the machine, or how fast they are. Many architectures do not make any mention of caches, although the processors that implement the architectures invariably have them.
In short, an architecture is a precise and complete description of the logical operation of a processor, and that logical operation should be independent of performance. All of the other details (number of execution units, caches, etc.) are things that are put into machines to help performance. These things should not alter the logical operation of the processor (i.e., they should not cause programs to generate outputs that could not have been generated were these things not in the processor). An example that captures this notion is as follows. If a person says "this processor executes instructions two-at-a-time," they are making a statement about the processor's implementation. On the other hand, if they say "this processor appears to execute instructions two-at-a-time," then they are making a statement about the processor's architecture. (Of course, this example assumes that there are programs that could produce results when executing instructions two-at-a-time that could not be produced when executing the instructions one-at-a-time. Otherwise, a person could not discern the appearance of two-at-a-time execution.)
In fact, a processor that has the appearance of executing instructions two-at-a-time is most probably nonsensical (if the statement of appearance is meaningful, as described above); that is, it probably does not do what most programmers would be expecting.
Further, in the example above, it is a safe bet that the person who is describing a processor that actually executes instructions two-at-a-time, is describing a processor that appears to execute instructions one-at-a-time. That is, the processor (unless it behaves nonsensically) produces outputs that are consistent with one-at-a-time execution. In fact, a processor that does execute instructions two-at-a-time must have some considerable amount of hardware that is only there to ensure consistency with one-at-a-time execution.
Therefore, when describing the logical appearance of the operation of a processor, we are describing the processor's architecture. The physical implementation of the processor is distinct from this, and is sometimes called the processor's "microarchitecture."
The microarchitecture is a description of the actual workings of the specific hardware of a specific processor. It describes one specific model of machine. On the other hand, the architecture might apply to many models of machines.
The reason that IBM was said to have had such success with the introduction of the 360 architecture in 1964 was that until then, no other company had cleanly defined a hardware-independent definition of the operation of a machine (architecture, as described above). All previous machines had their own hardware-dependent definitions--this meant that software that was developed for one machine could not be used on another machine. The IBM 360 line included some 20 models of different processors (each having a different cost and performance) that were all fully compatible at the assembly-language level.
This meant that customers could buy a machine that suited their performance requirements for a suitable cost, and if their performance requirements subsequently increased, the customer could upgrade to a new model of machine without having to discard the software that he had developed.
The IBM 360 architecture was defined by engineers in the late 1950's and early 1960's who used their best engineering judgement as to what a "good" instruction-set comprised. This involved making cost/performance trade-offs based on the hardware and software technologies of the late 1950's and early 1960's.
Of course, as these technologies evolved, the IBM 360 architecture fell behind. Since the IBM 360 line had been such a strong commercial success, IBM could not merely abandon the architecture; there was a loyal customer-base that had invested large amounts of money and time developing software that ran on this architecture.
Instead, IBM evolved the 360 architecture by defining upward compatible levels of the architecture (meaning that each generation's architecture subsumes the prior generation's architecture). This gave rise to the 370, and the 370 XA, and the ESA 390 architectures. The amount of money that has been spent in developing software for these architectures is thought to be in excess of two trillion dollars as of the early 1990's. Despite the fact that this architectural line is rooted in some things that are now antiquated, a $2,000,000,000,000 legacy is not easily abandoned.
U.S patent application Ser. No. 08/421,272 (IBM Docket No. YO995-057), filed concurrently herewith, which describes a Method and Apparatus for Improving System Performance in a Data Processing System, is incorporated herein by reference.